Present: Rich, Rob, Frederic, Conor and Kanna with Brian & Tom present for first hour

Quite a bit of progress has been made since these pages were last updated. Last week's (2/26) minutes were not posted. As of today, Rob's QNX stack has been "talking" to Conor's Mac with commands sent and state updates returned.

• Rich has been working on making changes to the behavior stack
  • Inserting behavior is done. Deleting a behavior to be executed in the future is relatively simple
  • It is believed that deleting a running behavior (per Hans) ought not to be a big deal too.
    • issue of clean up. Destructor class already exists; however it appears execution of destructors are not not done immediately. This was ok when the mission scirpt was pre-allocated and the vehicle had to go thru the entire set of actions. This ought to be verified with Hans (and the code base).
    • run time of clean up also need to be paid attention to, if there is substantial effort needed for this activity.
      • to alleviate this, the agreement now is that the AMC will instantiate the "next n" (perhaps n=1) behaviors to instantiate on the stack. This will ensure that the VCS can continue to execute thru without having to switch to an IDLE behavior in between.
      • an IDLE behavior will be sent over, prior to aborting a currently running behavior. This will ensure that the VCS has something to "chew" on while the cleanup and retasking is taking place both in the VCS and AMC respectively.
    • Precise details of deletion are still TBD; if it requires setting the duration of the behavior to current time or in the past, for termination, a public method will need to be implemented.
    • We'll need a separate log file to track when behaviors have started/ended. This will be in lieu of the current log file which is written to syslog.
• Conor has been working with Rich and Rob on passing messages between his Mac (AMC) and the QNX stack (VCS). This leverages code written by Rob to take advantage of the UDP protocol.
  • need to update Frederic's socket code which does not use UDP, but is easier for longer-term integration.
  • 3 timelines on the AMC side are maintained and loop closed with observations obtained from the state vector sent over from the "VCS"
  • goal requests are sent out as strings to the "VCS" which are used by Rich to insert behaviors on the stack.
    • need to send an associated behavior timeout along with these strings
• To do:
  1. convert Frederic's socket code to use UDP
  2. deletion of running behavior on the VCS side
  3. acknowledgement of behavior start/stop/abort; we will use a separate channel instead of state update
  4. Firing up the AMC stack to get metrics on EUROPA builds and run-time performance and to connect with the QNX stack to mimic actual hardware setup. This is now becoming critical for us to move forward. Hans in a subsequent conversation has promised getting the stack running by Tue 6th.
  5. Hans subsequently suggested connecting the AMC to the stack on the vehicle itself (which is not due to go out till Wed 7th morning). This would be an interesting test to do also.
• Schedule: We had a long conversation going over the detailed project plan and schedule. This followed a lengthy conversation between Rob, Rich and Kanna on Fri 2nd.
  • updated version of the schedule will be sent out within a day or so. This schedule prunes down the list of tasks, and focuses on the April sea-trial opportunity. Other tasks which are not on the critical path to this April event, will be revisited after the trial, allowing us all to focus on the essentials.
  • Monday 12th, we will discuss specific mission scenarios that we will aim for, for the April trial.
  • Current drivers are to demonstrate:
    • Waypoint changes (i.e change headings)
    • Surface Window Mgmt (ability to insert surfacing events into a plan when appropriate)
    • Shedding goals (in the light of timing/cost limitations)
    • Actuation of AMC
  • The last issue brought forth the need that we do need a way to reliably shut off the AMC from software. This calls for a h/w switch which will shut down the AMC, so that during nominal CTD runs, the AMC is not up and consuming energy and/or interfering inadvertantly with VCS execution.